-
Notifications
You must be signed in to change notification settings - Fork 169
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Add signal commands #20876
base: main
Are you sure you want to change the base?
feat: Add signal commands #20876
Conversation
This is not yet a complete signal implementation but only the low-level core data manipulation logic.
Quality Gate passedIssues Measures |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tried to do a fast review, except for the following bigger files, that will be reviewed in a second round:
- MutableTreeRevision
- TreeRevision
- MutableTreeRevisionTest
- TreeRevisionTest
} | ||
} | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
} | |
} | |
/** | ||
* Creates a new data node. | ||
* | ||
* @param parent | ||
* the parent id, or <code>null</code> for the root node | ||
* @param lastUpdate | ||
* a unique id for the update that last updated this data | ||
* node, not <code>null</code> | ||
* @param scopeOwner | ||
* the id of the external owner of this node, or | ||
* <code>null</code> if the node has no owner. Any node with | ||
* an owner is deleted if the owner is disconnected. | ||
* @param value | ||
* the JSON value of this node, or <code>null</code> if there | ||
* is no value | ||
* @param listChildren | ||
* a list of child ids, or the an list if the node has no | ||
* list children | ||
* @param mapChildren | ||
* a sequenced map from key to child id, or an empty map if | ||
* the node has no map children | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need this in case of a compact constructor?
I suggest keeping only the Creates a new data node.
sentence, and combine it with the next block of javadoc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It has no practical purpose other than to stop the checker from complaining about missing @param
values for the implicit method parameters.
* A signal command that doesn't apply any change but only performs a test | ||
* that will be part of determining whether a transaction passes. | ||
*/ | ||
sealed interface TestCommand extends SignalCommand { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I'm a bit biased, but the name TestCommand
(and further down ValueTest
, PositionTest
, and etc.) itches my mind. At first glance, it looks like a class that belongs to src/main/test
, but in reality it is used to verify a transaction. Could this be named as VerifierCommand
or something like that?
* @param listChildren | ||
* a list of child ids, or the an list if the node has no list | ||
* children |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems the sentence misses an empty
before the list:
* @param listChildren | |
* a list of child ids, or the an list if the node has no list | |
* children | |
* @param listChildren | |
* a list of child ids, or an empty list if the node has no list | |
* children |
* @param listChildren | ||
* a list of child ids, or the an list if the node has no | ||
* list children |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here. Though, I prefer to get rid of this almost duplicate block.
* @param after | ||
* id of the node to insert immediately after, nor | ||
* <code>null</code> to not define a constraint | ||
* @param before | ||
* id of the node to insert immediately before, nor | ||
* <code>null</code> to not define a constraint |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't these two be or
instead:
* @param after | |
* id of the node to insert immediately after, nor | |
* <code>null</code> to not define a constraint | |
* @param before | |
* id of the node to insert immediately before, nor | |
* <code>null</code> to not define a constraint | |
* @param after | |
* id of the node to insert immediately after, or | |
* <code>null</code> to not define a constraint | |
* @param before | |
* id of the node to insert immediately before, or | |
* <code>null</code> to not define a constraint |
/** | ||
* Gets the insertion position that corresponds to the beginning of the | ||
* list. | ||
* | ||
* @return a list position for the beginning of the list, not | ||
* <code>null</code> | ||
*/ | ||
public static ListPosition first() { | ||
// After edge | ||
return new ListPosition(Id.ZERO, null); | ||
} | ||
|
||
/** | ||
* Gets the insertion position that corresponds to the end of the list. | ||
* | ||
* @return a list position for the end of the list, not | ||
* <code>null</code> | ||
*/ | ||
public static ListPosition last() { | ||
// Before edge | ||
return new ListPosition(null, Id.ZERO); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if I easily understand this part:
The description of the after
param says: id of the node to insert immediately after...
and description of the before
param says: id of the node to insert immediately before...
What is the role of the ZERO
? Is the ZERO
an always existing root pointer that will store the head position (or the head == tail == ZERO in case of an empty list)?
If so, calling first()
returns the before first (after the ZERO) position which makes sense. But, the last()
returns before the ZERO, which I don't simply get :)
Probably, something in the implementation is being optimized by this(?), but this representation seems a bit confusing.
* @return the single operation, not <code>null</code> | ||
*/ | ||
public TreeModification onlyUpdate() { | ||
assert updates.size() == 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to the Javadoc of Accept
, the updates
can be more than one, so is the assertion here supposed to prevent this method to be called in places when more than one update is applied to a signal? If yes, throwing an IllegalStateException
makes more sense, since the assertions may not be enabled at runtime.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This reuses the convention from various internal Flow classes to use assert
to check for things that could only (reasonably) be bugs in other parts of framework code but shouldn't be causable by (reasonable) application code.
* @return an accepted result if the condition is <code>true</code>, a | ||
* rejected result if the condition is <code>false</code> | ||
*/ | ||
public static OperationResult test(boolean condition, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor: suggesting to rename to something like verify
:
public static OperationResult test(boolean condition, | |
public static OperationResult verify(boolean condition, |
|
||
import com.vaadin.signals.Id; | ||
|
||
public class OperationResultTest { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There could be more tests here to have better coverage of all the implementations, especially verifying the Accept#onlyUpdate
, and the test
behaviour.
This is not yet a complete signal implementation but only the low-level core data manipulation logic.